如果你有約七個後端與資料庫工程師，四個前端工程師，年資0到8年不等，大家合作從零開始打造這個產品，開發期一年半，已經線上運作兩年，產品的市場反應狀況還不錯。你是整個團隊的主管，怎麼面對前有市場期待的需求在排隊，後有線上問題在放火的情況?

有產品在線上運作的狀況，從上帝視角來看就有點像是線上遊戲經營便利商店，客訴會讓你扣分，等太久客人消費力會減少甚至客流量消失，新產品會讓客人加分，好的動線就會有好的購物體驗也會加分，如果上到爆款商品則讓整個商店擠滿人，然後在調整之前就進入了一個客訴的循環。

我的思維說出來可能我會發現我老闆在我背後想炒了我。如果線上有可以持續創造收入的東西在線上，面對新需求與優化的需求，我會選擇犧牲新需求優先處理優化的需求，讓線上穩定。我會這樣的選擇是因為我認為要把人當人。線上出問題的時候需要燃燒大量腎上腺素，處理完後大概整天都是喪屍狀態了。如果在還要在這樣的狀態下持續開發新功能，難保會不會在新功能中又埋下了新的BUG。所以在選擇上我希望工作團隊能保有最好的工作狀態，以及信任團隊夥伴能在好的工作狀態下其實能提早把專案完成，其實最終還是會對產品是好的。

但是如果自己線上的產品才剛上線，可能還在打開知名度的過程，做法會不一樣嗎?我會說基本上看產品類型與看狀況。產品才剛上線，通常會伴隨著行銷資源的投入，如果花錢把人導流到一個有問題的東西上，錢投入沒有得到效益是一件事，品牌被流量嘲笑才是另外一個難以處理的問題，所以行銷期還是乖乖優先修正BUG才是正途。但如果還在蟄伏的情況，或者東西並不是壞在一個很重要的地方，我建議判斷功能使用率的數據來評估是否先完成手上新功能專案再花時間去修正或優化東西。

那如果是純維護型的專案，時間會怎麼分配呢？趕快了解這些專案哪一個死掉會讓你沒工作(不管是政治面還是財務面)，趕緊把焦點放在上頭吧。要花時間了解整個專案架構，使用資源與平常哪邊容易壞掉，要能用自己的視角去把架構圖畫出來，常死掉的地方確定是否有足夠的線索(log)，看看能不能做出警示的功能，幫自己先畫出一條守備防線，在問題發生前盡可能作出應變。

但不管是哪一類型的專案，一定要提早把最重要的基礎建設給搞定：部署流程。一般的工作團隊應該會讓大多數的工程師只碰得到git，也就是你程式碼上git後，就會觸發約定好的團隊CI流程，以及最終讓更新上線的CD流程。對我來說 CI 是工程師之間的良心，要怎麼跑都有每個團隊的想法與不同狀況，因此是另外一大塊議題，但CD就不同了，他會是影響工程師更新過程與客戶體驗上的一個很重大的環節。例如後端API更新時，是否有可能會造成程式執行中斷，導致個動作只執行一半難以修復問題？

在我那次美好的專案開發經驗中，團隊一樣規劃了讓大部分工程師只要面對git即可，但後續不斷的進行CD流程上的補強。例如不斷壓縮CD的時間，讓該次更新結束git CI流程後，3分鐘內就可以完成全部服務的更新；而因為是K8S的服務，我們也將開始部署與完成部署的通知，發到通訊軟體中，讓更新者知道更新進度，以便於後續第一時間檢查。

因為有了這樣的基礎建設，不論在功能開發上或者BUG修正優化上縮短了等待時間，開發團隊可以更有效率的工作。

而這樣的CD環境建立，是在我們服務從零開始，還在開發需求的時候，撥出了兩個較為資深的夥伴開始預備這樣的工作流程，一直沿用到今天。

而回答我一開始的問題，怎麼面對前有市場期待的需求在排隊，後有線上問題在放火的情況。小孩子才做選擇，事前的需求範圍管理，與開發中後期的測試做足，檢測工具與模擬問題現實的處理SOP都做好，讓這些工作都應該要算在需求開發期的時間內，自然比較少產生線上問題的臨時狀況。而這些傳統開發工作以外的東西算進來會不會膨脹原本的需求開發時間？會，但只有初期大家不習慣這樣思維的時候才會，但是當大家理解先把這類問題規劃起來的時候，開發的品質無形當中就會進步，工程師就不會設計出不能維護或者資料修復的架構。

這就是堆疊每一個專案的經驗，逐步累積，變成未來新專案的基礎，如此循環，自然就會變成一個加速器，越來越好。

什麼？你現在時間真的不多抽不出時間？真正敏捷思維的人是不會講出這句話的。